Frank Kjul Larsen’s reputation | Open Source Tools for Renesas

Frank Kjul Larsen’s reputation

Frank Kjul Larsen 19 Rep.

Follow

Frank Kjul Larsen's reputation

Total 19

0,0,0,0,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

+2

April 12, 2024 Asked Which CPU to select for RX26T compilation.

+1

January 26, 2021 Commented Hello Robert OK. I changed to use newlib-nano by exchanging use of optimised lib C and lib Math. OPTIONS += -loptc OPTIONS += -loptm with OPTIONS += -lc OPTIONS += -lm OPTIONS += --specs=nano.specs OPTIONS are CFLAGS and I activate the linker through GCC. After changing to newlib nano, I had to implement two more functions in order to link: void *sbrk(intptr_t increment) { (void)increment; return 0; } _Noreturn void _exit(int status) { exit(status); } The good thing is that now the number warnings does not depend on the optimisation level:-) The code size is less than before:-) The code still executes:-) BR Frank

+1

January 26, 2021 Commented Hello NoMaY-jp I just compile ordinary C-code, not C++. I compile from command line using makefile not using E2 studio. I call the compiler like this (I've remove some include path to make it less messy): rx-elf-gcc -c -Isource -Drx71m -mcpu=rx71m -mlittle-endian-data -D__RX_LITTLE_ENDIAN__=1 -std=c11 -nostartfiles -Wall -Wextra -Wl,--warn-common -Wl,--gc-sections -ffunction-sections -fdata-sections -DROMSTART -loptc -loptm -DPRINTF -O3 -g2 -o obj/source/main.o source/main.c My project consists of several files - makes a binary of >100 kB at -O3, thus it makes no sense to post them. I just wanted to tell GNU tools that I experience this behaviour. It seems that in their investigation they see same behaviour regarding link errors when using printf using -O0 and -O3. I therefore suspect another setting in my setup to cause my trouble. But I know how to handle it, so I will leave it for now. This discussion will show other users what they can do. Thanks for your effort. BR Frank

+1

January 26, 2021 Commented Hello all I cannot send all my source code, but I can be more specific on how I compile and link. I compile for a RXv2 MCU - RX71m. I use my own start file. I execute from flash. OPTIONS += -mcpu=rx71m OPTIONS += -mlittle-endian-data # Select little endian operation OPTIONS += -D__RX_LITTLE_ENDIAN__=1 OPTIONS += -std=c11 OPTIONS += -nostartfiles OPTIONS += -Wall OPTIONS += -Wextra OPTIONS += -Wl,--warn-common OPTIONS += -Wl,--gc-sections OPTIONS += -ffunction-sections OPTIONS += -fdata-sections OPTIONS += -DROMSTART OPTIONS += -loptc OPTIONS += -loptm # Optimisation OPTIONS += -O3 or # Optimisation OPTIONS += -O0 BR Frank

+1

January 25, 2021 Commented To be honest, I have not used printf() before with the RX tool chain. Last time was with GNU H8 toolchain. The core of my question is why the behaviour is different at different optimisation levels on the newest RX toolchain. BR Frank

+2

January 22, 2021 Asked printf() usage in RX toolchain 20.04 change when optimisation change

+1

December 13, 2019 Commented Hello GNU tools I have now had the opportunity to test your new toolchain on one of my RX111 targets, and I want to share my impressions with other users. My tests have been using the Windows version and not the one refreshed today. My first impressions is that the binary it produces is denser, faster and contains less errors. My code compiled and executed first time with no modification from the earlier RX 1902_sp1 version. I only changed the path to the new toolchain 6 warnings was issued during compile. I use the following compiler options: # Common options OPTIONS := -DRX111 OPTIONS += -mcpu=rx100 OPTIONS += -nofpu OPTIONS += -mlittle-endian-data # Select little endian operation OPTIONS += -D__RX_LITTLE_ENDIAN__=1 OPTIONS += -std=c11 OPTIONS += -nostartfiles OPTIONS += -Wall OPTIONS += -Wextra OPTIONS += -Wl,--warn-common OPTIONS += -ffunction-sections OPTIONS += -fdata-sections OPTIONS += -Wl,--gc-sections OPTIONS += -DROMSTART OPTIONS += -loptc OPTIONS += -loptm # Optimisation OPTIONS += -O3 # Debug info in file (not with list files) OPTIONS += -g2 The parser found more errors in my code - shown as warnings: - a logical AND that should have been a bitwise AND - an if statement that lacked the {} block. - an snprintf that truncated number to be converted to a string by accident. - a intentionally fall through in a switch. That was not an error. and more. Who needs tools for static code analysis any more? These errors was not found by a very expensive SW analysis tool. The code is even more compact as it was before:-) The code is faster. I used to have a loop time of 500 us and that is now 394 us:-) This new toolchain is certainly worth trying. I think you have done a great job. Thank you so much GNU tools. Best regards Frank Kjul Larsen

+1

December 2, 2019 Commented Hello GNU Tools. Thank you very much:-) What a leap. I certainly miss superlatives. I feel very exited to start using this new modern compiler for my RX projects. Best regards Frank Kjul Larsen

+2

October 2, 2018 Asked Will fixed-point math be supported?

+1

October 16, 2017 Commented Hello GNU Tools Support It certainly solves the problem. I can use optlib under Linux again:-) The binary output from the Windows and the Linux tool chain has the same size and performs equal. Thank you very much! Best regards Frank Kjul Larsen

+2

October 9, 2017 Asked Difference between Windows and Linux RX 1703 toolchain when using optimised libraries

+1

September 29, 2016 Commented Thank you - this solves my problems. I find both the Windows and the Linux version of v12.02. Excellent! BR Frank

+2

September 23, 2016 Asked Where are the 12.02 Linux and Windows versions of the H8 GNU tool chain?

+1

August 8, 2016 registration

Support